In file @packages/client-runtime/src/state/shell.ts around line 138:

`applyItem` checks `hasServerBackedSnapshot` and `current.snapshot` at the top of the `fromDisk` path but the check is not atomic with the state update at the bottom. If `setDisconnected` starts `applyDiskFallback` concurrently with an HTTP heal, the disk fiber can pass the guard, yield, then resume after the HTTP fiber installs its authoritative snapshot — and overwrite it with the stale cached snapshot, reintroducing archived threads that the heal removed. The `fromDisk` guard needs to be rechecked immediately before committing the disk snapshot (or serialized with the state update) so a concurrent authoritative heal wins.

In file @apps/mobile/modules/t3-composer-editor/android/src/main/java/expo/modules/t3composereditor/T3ComposerEditorModule.kt around lines 52-59:

Android hardware-key submit does not work: `T3ComposerEditorModule` omits the `onComposerSubmit` event and `T3ComposerEditorView` has no hardware-key handler, so pressing the documented submit shortcut on Android never emits a submit event or invokes `handleSend`, unlike iOS which emits `onComposerSubmit` for Command-Return. Register an `onComposerSubmit` event in the `Events(...)` list and add an `OnKeyListener` (or equivalent) on the editor that emits it for the Android submit shortcut.

Also found in 1 other location(s):
- apps/mobile/src/native/T3ComposerEditor.native.tsx:87 -- `ComposerEditor` does not destructure or forward the public `onSubmit` callback to the Android native view. Existing callers such as `ThreadComposer` pass `onSubmit={handleSend}`, so the documented hardware-keyboard submit shortcut is silently ignored on Android, unlike the iOS implementation which forwards `onComposerSubmit={onSubmit}`.

In file @packages/client-runtime/src/state/server.ts around line 172:

The finalizer at line 172 saves the pending config, but it runs *before* the persistence worker fiber is interrupted because Effect finalizers execute in reverse registration order. When the scope closes, the finalizer can write config B while the worker is still writing an older config A; if the worker's write finishes after the finalizer's, it overwrites the cache with stale data. Join or stop the worker before flushing in the finalizer, or serialize both paths through the same lane.

Also found in 1 other location(s):
- apps/mobile/src/persistence/mobile-storage.ts:167 -- `saveConnection` performs an unprotected read-modify-write of the entire `CONNECTIONS_KEY` value (and `clearSavedConnection` does the same). If two connection saves, or a save and clear, run concurrently, both can read the same old list and the last write silently discards the other operation, losing a saved connection or resurrecting a cleared one. These operations need to share a lock around the complete read/write transaction.

In file @apps/mobile/src/components/AppSymbol.tsx around line 190:

`SymbolView` renders nothing on Android for SF symbol names that are missing from `ANDROID_ICON_BY_SF_SYMBOL`, and callers pass no `fallback`. Several reachable call sites use names that are omitted from the map — for example `arrow.down` on the queue move-down button, plus `list.number`, `hourglass`, `arrow.counterclockwise`, and `arrow.up.right.square` — so those icons disappear on Android, including an actionable queue control. The fallback branch at line 190–192 returns `props.fallback ?? null`, which is `null` for these callers. Add the missing SF-symbol-to-Tabler mappings for all call sites (or supply a generic fallback) so every symbol used through the wrapper has an Android glyph.

In file @apps/mobile/modules/t3-review-diff/android/src/main/java/expo/modules/t3reviewdiff/T3ReviewDiffView.kt around line 583:

When `rows` is replaced with a new list that occupies the same index range as the current viewport (e.g. a same-sized diff at offset 0), `onVisibleRowsChanged` is not emitted for the new content. The `rows` setter calls `rebuildOffsets()` but never clears `lastVisibleRange`, so `emitVisibleRange()` still sees the old `(first, last)` pair, treats it as already-emitted, and suppresses the callback. Consider resetting `lastVisibleRange = null` in the `rows` setter so the next `invalidate()` re-emits the visible range for the new content.

In file @apps/mobile/src/persistence/mobile-storage.ts around line 157:

`loadSavedConnections` accesses `connection.environmentId` on each array element without first checking that the element is an object. A persisted payload like `{"connections":[null]}` throws a `TypeError` while loading connections, instead of ignoring the malformed entry. Since `saveConnection` and `clearSavedConnection` both read the current list before writing, this crash also blocks any save or clear operation once a `null` element is present in storage. Add a guard (e.g. `connection != null && typeof connection === "object"`) inside the `Arr.filter` predicate before dereferencing properties.

In file @apps/mobile/src/native/nativeStackOptionsSignature.ts around line 12:

`buildNativeStackOptionsSignature` only hashes a fixed allowlist of fields, so changes to any other `NativeStackScreenOptions` property (e.g. `headerShown` changing from `true` to `false`) produce an identical signature. The caller then skips `setOptions`, leaving the screen with a stale navigation configuration. Include every forwarded option in the structural comparison, applying special handling only where needed.

Also found in 1 other location(s):
- apps/mobile/src/native/StackHeader.tsx:114 -- `lastSignatureRef` skips `navigation.setOptions` based on a lossy signature: `buildNativeStackOptionsSignature` covers only a small subset of `NativeStackNavigationOptions` and replaces functions inside options such as `headerSearchBarOptions` with `"[fn]"`. If an omitted option changes, or a caller supplies a new search callback with otherwise identical options (as `ThreadNavigationSidebar` does), the signature remains unchanged and navigation retains the previous value/closure. This can leave screen configuration stale and dispatch search changes to an obsolete callback. Either include all option values with callback-safe wrappers, or limit this deduplication to the specific stabilized factories.

In file @apps/mobile/modules/t3-terminal/android/src/main/java/expo/modules/t3terminal/TerminalCanvasView.kt around lines 37-42:

If `fonts/MesloLGS-NF-Bold.ttf` is missing or invalid while the regular asset loads successfully, `regular` is updated to the Meslo face but `bold` stays at the default `Typeface.MONOSPACE` fallback. Because the terminal cell width is derived from the regular face, bold text then renders with mismatched glyph metrics, causing misaligned or overlapping cells. Assign to locals first and publish both only after both loads succeed, or derive `bold` from the loaded regular face so the metrics stay consistent.

In file @apps/mobile/src/features/settings/SettingsRouteScreen.tsx around line 319:

`savePreferences({ liveActivitiesEnabled: true })` on line 319 is called fire-and-forget after `setLiveActivityUpdatesEnabled` already committed the relay preference. If the local preference save fails, `updateMobilePreferencesAtom` rolls back its optimistic value — so the UI reverts to "disabled" while the relay stays enabled. The same divergence happens on the disable path (line 403): the relay is disabled but the local preference silently rolls back to enabled. In both cases the switch state and actual delivery behavior become inconsistent. Consider awaiting `savePreferences` and reverting the relay preference (or surfacing an error) when the local save fails.

In file @apps/mobile/modules/t3-terminal/android/src/main/java/expo/modules/t3terminal/T3TerminalView.kt around line 388:

The `themeConfig` setter calls `parseThemeConfig(value)` without first resetting `cursorColorValue` and `paletteColors`, so changing to a theme that omits `cursor-color` or `palette` entries leaves the previous theme's cursor color and palette in effect. Setting `themeConfig` to `""` (or to a config that only changes a subset of colors) renders a mix of old and new theme colors instead of the requested theme. Consider resetting `cursorColorValue` and `paletteColors` to their defaults at the start of `parseThemeConfig` before applying the new config.

In file @patches/react-native-keyboard-controller@1.21.13.patch around line 1115:

`anchorToEnd` on open compares the scroll offset against `blankSpace.value`, but the true rest position is `Math.max(blankSpace.value, padding.value + extraContentPadding.value)`. When `extraContentPadding` exceeds `blankSpace`, a user sitting above the real end of the scroll range is incorrectly flagged as anchored. The `anchorToEnd` branch then calls `scrollTo` with the live maximum scroll offset on every keyboard frame, jumping the conversation to the newest message and losing the user's reading position. Use the same `Math.max(blankSpace.value, padding.value + extraContentPadding.value)` calculation that the close path already uses when setting `anchorToEnd` on open.